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(54) Title: METHOD FOR CONTROLLING THE EXECUTION OF A REQUEST FOR ACTION TRANSMITTED BY A SERVER TO 
A CHIP CARD VIA A TERMINAL 

(54) Titre: PROCEDE DE CONTROLE DE L'EXECUTION D'UNE DEMANDE D* ACTIONS TRANSMISE PAR UN SERVEUR VERS 
UNE CARTE A PUCE VIA UN TERMINAL 

(57) Abstract 

The invention concerns a method for exchanging synchronised mes- 
sages between an application server and at least a chip card, wherein the 
card transmits a message to the server containing the latest current value of 
an action counter stored by the server; the server emits a message comprising 
a request including one or several actions to be implemented by the card and 
stores the number n of actions of the request; the card receives the message, 
successively executes the action or actions in the request incrementing its ac- 
tion counter between each action if the action has been successfully executed; 
when there is a request for a transaction by the card, the server compares the 
received action counter value with the latest value stored, incremented by the 
number of actions contained in the previous request for actions and, operates 
on the basis of this comparison. 
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(57) Abr^ge 

L* invention concerne un proo6d6 d'echange de messages avec synchro- 
nisation entre un serveur d* application et au moins une carte a puce. Pour 
cela la carte transmet un message au serveur contenant la dernfere valeur 
courante d'un compteur d 'actions que le serveur stocke; le serveur 6met 
un message comportant une demande comprenant une ou plusieurs actions 
a mettre en oeuvre par la carte et stocke le nombre n d' actions de la de- 
mande; la carte recoit le message, execute successivement la ou les actions 
de la demande en incrementant son compteur d' actions entre chaque action 
si 1 'action s'est bien exdeutee; lors d'une demande de transaction par la 
carte, le serveur compare la valeur du compteur d' actions recue, a la dernifcre 
valeur stockee, incr6ment6e du nombre d' actions contenues dans la demande 
d* actions precedence et, exploite le resultat de cette comparaison. 
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PROCEDE DE CONTROLE DE L' EXECUTION D ' UNE DEMAND E 
D 'ACTIONS TRANSMISE PAR UN SERVEUR VERS UNE CARTE A 

PUCE VIA UN TERMINAL 

La presente invention concerne les systemes 
d' echanges de messages entre seryeur d ' application et 
cartes . a v puce empruntant un reseau de communication. 
Elle s 7 applique aux echanges s'effectuant a travers les 
reseaux de telecommunication, reseau telephonique 
commute, reseau cellulaire ou reseau Internet. 

Generalement , les messages echanges entre un 
serveur d' application et 1 ' application correspondante 
dans une carte a puce transitent par un equipement 
intermediaire que l'on designera par terminal dans la 
suite. La carte a puce d'un utilisateur coopere avec le 
terminal pour permettre les echanges. 

Dans le cas ou le reseau emprunte est un reseau de 
telephonie, le terminal est un terminal de 
5 telecommunication. Dans le ' cas ou le reseau emprunte 

est un reseau inf ormatique , le terminal est un 
equipement inf ormatique de type ordinateur equipe d'une 
interface de lecture/ecr iture de cartes a puce. 

Un serveur sous controle d'un organisme emetteur de 
0 carte, desirant effectuer une action securisee dans une 
carte a puce (ou dans une application de ladite carte) 
via un reseau telephonique, utilise des certificats 
cryptographique permettant d ' assurer la securite des 
echanges . 

5 Cependant, en cas de perte d'un message durant la 

transmission ou 1' execution ou en cas de tentative de 
fraude, la re-synchronisation des messages serveur- 
cartes peut poser des problemes securitaires . 

Dans le cas ou le terminal est un terminal dedie et 

0 securise sous controle de 1 ' organisme emetteur (par 
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exemple un distributeur automatique de billets DAB sous 
controle d'une banque) , la perte d'un message est 
coropensee par des mecanismes de synchronisation mettant 
en jeu a la fois le logiciel du serveur et le logiciel 
du terminal dedie. Le terminal dedie est securise soit 
physiquement (DAB) soit contient a 1'interieur un 
module SAM (Secure Authentication Module) , et dans tous « 
les- cas est controle etroitemenj: par 1 / organisme 
emetteur . • • ' 

Si le terminal. utilise n'est pas un terminal dedie 
et securise (par exemple telephone GSM, PC sous 
Internet,...), les mecanismes de synchronisation ne 
peuvent pas etre bases sur la securite du terminal, du 
fait que celui-ci n'est pas controlable par 1' emetteur. 
15 En effet, il est important de pouvoir re- 

synchroniser la source des messages et la carte a puce 
en cas de probleme de transmission sur le reseau.. Ce 
probleme a ete pose en terme de securite vis-a-vis des 
operateurs et des fournisseurs de service. 
20 11 n'existe pas a ce jour de -systeme prevu pour 

assurer une synchronisation entre la carte et le 
serveur, dans les cas ou pendant . une transaction en 
cours, acceptee par consequent par la carte, le serveur 
profite de la connexion pour envoyer un message 
25 comportant une ou plusieurs actions a mettre _en oeuvre 
par la carte, ces actions pouvant etre par exemple un 
rechargement d' unites de valeur ou de parametres 
(monetaires ou autre) ou un chargement d'une nouvelle 
application. 

En effet, il est prevu dans le cadre plus general 
des cartes multi-applicatives , q Ue des message soient 
envoyes alors que 1 ' utilisateur a fait une demande de 
.transaction afin d' envoyer des. commandes "pour des 
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actions a entreprendre pendant: le deroulement de 
1 'application pour la transaction en cours. 

De tels messages permettront par exemple de 
commander un rechargement de porte-monnaie electronique 
5 dans le cas d'une application porte-monnaie 
electronique, ou de modifier des parametres bancaires 
de 1 ' application bancaire, ou le chargement d'une 
} nouvelle application dans la carte. 

II est clair que dans cette situation, le serveur 
10 ne sera pas informs dans le cas ou ledit message est 
perdu . 

En d'autres termes, effectuer des actions 
securisees sur un terminal non dedie est faisable 
aujourd'hui mais impose, soit des contraintes 
15 utilisateur fortes (cartes ou applications bloquees si 
1' action securitaire n'est pas parvenue a terme) , soit 
des risques de perte d ' informations (par exemple perte 
d'une transaction de rechargement d'un porte-monnaie 
electronique) . 

20 

Le but de 1' invention est que le serveur puisse 
detecter les defauts d' execution d'une ou plusieurs 
actions ou commandes, lies a une perte de messages 
entre le serveur et la carte a puce ou a des defauts 

25 d' execution d' actions dans la carte, lesdits messages 
ayant ete transmis a la carte eventuellement pendant 
une transaction en cours, ceci afin d'en informer le 
serveur pour que ce dernier determine quelles sont les 
dernieres actions ou commandes non executees par la 

3 0 carte. 

Selon une procedure pre-etablie en fonction de la 
ou des actions non mises en oeuvre, le serveur pourra 
par exemple renvoyer le message ' contenant la dite ou 
les dites actions et permettre leur execution. 
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A cette fin, 1' invention a particulierement pour 
ob jet un precede de controle de 1' execution d'une 
demande d' actions transmise par un serveur vers une 
carte via un terminal, ladite carte comportant un 
5 compteur d' actions, caracterise en ce qu'il comporte 
les etapes suivantes : 

; a) a l'emission par le serveur ^ d'un message 
comportant une demande comprenant une ' ou plusieurs 
actions a mettre en 'oeuvre par- la carte, le serveur 
10 stocke le nombre n d' action de la demande; 

b) a la reception du message, la carte ' execute 
successivement la ou les actions de la demande en 
incrementant son compteur d' actions entre chaque 
actions si 1' action s'est bien executee et en refusant 

15 cette action et les actions successives si 1' action ne 
s'est pas bien executee sans incrementer son compteur. 

c) on compare la variation entre la valeur dans 
la carte et celle stockee dans le serveur et on 
determine que les x dernieres actions (commandes) ne 

20 sont pas executees si le resultat de la comparaison 
presente un ecart de x. 

L' incrementation du compteur d' action correspond au 
nombre d' actions correctement executees. 

Le nombre x est egal a 0 si toutes les actions sont 
25 correctement executees, ce nombre x peut done varier 
de 1 a n si la derniere ou toutes les actions ont 
echoue. 

Pour comparer la variation entre la valeur dans la 
carte et celle stockee dans le serveur, la carte 
transmet au serveur la valeur courante de son compteur 
avant et apres execution de la commande d' actions. 

Pour comparer la variation entre la valeur dans la 
carte et celle stockee dans le serveur, la carte 
calcule la valeur de la variation de son compteur suite 
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a 1' execution de la commande d' actions et la transmet 
au serveur. 

Selon une autre caracteristique, tout echange de la 
valeur du compteur d'actions de la carte est effectue 
systematiquement de maniere securise. 

A cette fin, la derniere valeur du compteur 
d'actions de ( la carte est transmise avec un 
cryptogramme dont le calcul impliqu^e la dite derniere 
valeur . 

Selon une autre caracteristique la derniere valeur 
courante du compteur d'actions de la carte est 
transmise au serveur en temps reel, c'est-a-dire 
pendant la transaction en cours. 

Selon un exemple la valeur pourra etre transmise au 
moyen du message d'acquittement de la transaction en 
cours dans la carte* 

•Selon une autre caracteristique la valeur du 
compteur d'actions de la carte est transmise au serveur 
en temps differe. 

Selon un exemple la valeur du compteur d'actions 
pourra etre transmise au moyen d'un message d'une 
nouvelle demande de transaction par la carte par le 
serveur. 

Selon un autre exemple la valeur du compteur 
d'actions de la carte est transmise au moyen d'un 
message d ' information emis pour la carte au serveur. 

L' invention a egalement pour objet une carte pour 
mettre en oeuvre le procede precite comportant un 
compteur et des moyens de gestion de ce compteur, 
caracterisee en ce que lesdits moyens de gestion sont 
aptes a incrementer ledit compteur d'actions entre 
chaque action si 1' action s'est bien executees et a ne 
pas 1 ' incrementer pour cette action ni pour les actions 
suivantes si cette action n'a pas ete executee. 
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D'autres caracteristiques et avantages de la 
presente invention apparaltront a la lecture de la 
description ci-apres donnee a titre d'exemple non 
limitatif et en regard des dessins sur lesquels : 

- la figure 1, illustre des echanges de messages 
eritre serveur et carte £ puce selon 1' invention, 

) ~ la f ig™ 2, illustre de maniere detai'llee des 
echanges de messages entre serveur et carte a puce dans 
le cas d'une perte de message, 

- la figure 3, illustre un autre cas de perte de 
message. 

on entend par demande d' actions, un message 
15 comportant un jeu de n commandes , n pouvant bien 
entendu etre egal a 1. 

On pourra se reporter pour mieux comprendre la 
suite au schema de la figure 1. 

Dans toute la suite, on a pris comme exemple le cas 
ou le serveur 2 profite d'une transaction en cours dans 
une carte 1 pour lui envoyer une demande comportant une 
ou plusieurs actions que la carte devra executer. 

Bien entendu dans ce cas une demande d' action sera 
emise avec la reponse a la transaction en cours si 
ladite transaction necessite une reponse. Si ce n'est 
pas le cas, cree une reponse contenant uniquement la 
demande d'actions. Le terminal qui est en communication 
avec le serveur recoit le message correspondant a cette 
reponse, epure ce message de son enveloppe pour 
transmettre les actions a la carte. 

Une demande d'actions peut comporter plusieurs 
actions a entreprendre par la carte, c'est-a-dire comme 
precise au debut de la description, . un jeu de 
n commandes . ' 
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A titre d' exemple une demande d' actions pourra etre 
une demande de changement d'un ou plusieurs parametres 
dans un programme d 9 application ou, le chargement d'une 
nouvelle application ou, - le chargement d'unites de 
5 valeur. 

Le changement d'un parametre correspond a une 
action pour la carte qui est une operation • d ' ef f acement 
et ;ecriture a une adresse predeterminee . \ 

Le changement de plusieurs parametres correspond a 
10 autant d' operations d'eff acement et ecriture a des 
adresse distinctes que de parametres et par consequent 
a autant d' actions a entreprendre qu'il y a de 
parametres a changer . 

On va maintenant detailler ce qui se passe cote 
15 carte et cote serveur. 

Cote carte : 

La carte 1 incremente apres chaque action 
correctement effectuee, le compteur d 7 actions CA des 
qu'elle revolt du serveur une ou plusieurs actions a 

2 0 entreprendre et qu'elle a pu mener a bien 1' execution 
de chacune de ces actions. 

La valeur du compteur est remontee vers le serveur 
par exemple chaque fois que la carte envoie un message 
au serveur (message 3 ou message 4 sur la figure 1). 

2 5 .La valeur du compteur peut etre remontee vers le 

serveur 2 essentiellement lors des actions suivantes : 

- lorsqu'il y a un acquittement de transaction (si 
durant une transaction un message d ' acquittement est 
remonte au serveur on peut mettre dans cet acquittement 

30 la valeur du compteur d'actions), (exemple : 
message 3) , 

- lorsqu'il y a une demande de transaction ou 
d ' authentif ication de la carte vers le serveur, 
(exemple : message 4)', 
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- dans le cas de cartes bancaires ou de porte- 
monnaie electronique : 

- on stocke dans chaque terminal 3 toute 
transaction passee, 

- la transaction stockee est remontee au serveur 
pour que le serveur puisse enclencher le processus de 
paieirtent ^ du marchand aupres duquel a eu lieu la 
transaction, le compteur d' actions CA peut etre remonte 
avec cette transaction. 

Ainsi, la valeur du contenu du compteur d' actions 
est toujours remontee au serveur soit en temps reel 
lorsque cela est fait lors d'un acquittement ou en 
temps differe lors d'une nouvelle demande de 
transaction ou lors d ' une remontee d ' un stockage de 
15 transactions. 

Cote serveur : 

Pour chaque carte contenant une application qui lui 
est dediee ayant une demande d' act ions en cours, le 
serveur doit stocker : 
20 " le numero d' identification de . 1' application, 

- la valeur courante du compteur- d' actions, 

- la liste des actions, en cours pour cette carte. 
Ainsi, le serveur auquel appartient une application 

placee dans une carte a puce multi-applicative, peut 
25 lors de n'importe quelle transaction demandee par la 
carte, commander une action telle qu'un rechargement 
d' unites, ou qu'un chargement d'un programme ou qu'un 
chargement de nouveaux parametres pour un programme 
residant dans la carte., 

Le serveur peut ainsi envoyer des actions a la 
carte par un mecanisme de script non interpretable par 
le terminal 3, qui se trouve entre le serveur et la 
carte pour assurer la communication. Le terminal 3 
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transmet le ou les messages recpus dans le script a la 
carte de maniere transparente. 

On va maintenant detainer 1' ensemble des 
5 traitements dans le cas ou la remontee du contenu du 
compteur d' actions se fait en temps reel et dans le cas 
ou tout-: se passe bien, c'est-a-dire dans le cas ou il 
n'y a pas de perte de message et ou 1' execution par la 
carte s'est bien deroulee. 
10 On pourra se-. reporter au mode de realisation 

particulier illustre par le schema de la figure* 1 pour 
mieux comprendre, 

- A 1 ' instant dti le porteur- demande via son 
terminal 3 une transaction ( un paiement ou une autre 

15 .transaction) : message 1. 

- La carte prepare la transaction et un 
cryptogramme , c'est-a-dire les donnees 
d ' authentif ication , designees par la suite par MAC et 
transmet au terminal. 

20 Associe a cette transaction, 1 ' application bancaire 

joint la valeur actuelle CA de son compteur d' actions 
securise par le cryptogramme. 

- Le terminal remonte la transaction au serveur 
bancaire. 

25 De facpon pratique, la carte envoie un message de 

demande de transaction contenant les donnees MAC1 ainsi 
que la valeur du compteur d ' action CA, et 
1 9 identification de la transaction demandee. 

- Le serveur verifie les donnees d ' authentif ication 
30 de la carte MAC1 et traite la transaction. Le serveur 

peut a ce moment effectuer une action dans 
1 ' appl ication de la carte. 

Selon un exemple particulier, il peut s'agir d'un 
chargement de parametre monetaire dans la carte, mais 
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comme cela a ete dit, d'autres actions du type 
rechargement d'un porte-monnaie electronique sont 
egalement possibles. 

- Pour cela, le serveur va preparer une ou 
5 plusieurs commandes de chargement de parametres 

contenues dans un champ d' information denomme ci-apres 
J script 1, et les donnees d'authenti'f ication securitaire 

) MAC2. ) \ 

- La demande d ' action est envoyie par un message 2 
10 qui peut contenir la reponse a la transaction en cours 

si une telle reponse est prevue pour 1 ' application 
concernee. 

Au moment de 1' envoi du script 1 a la carte, le 
serveur stocke dans une base de donnee ce script 1, en 

15 y associant les donnees relatives a la carte, ainsi que 
la valeur courante CA du compteur d' actions de la carte 
(remontee de la carte vers le serveur durant la demande 
de transaction) . Ces informations vont permettre 
d'effectuer la synchronisation serveur-carte. 

20 - La carte qui recpoit les commandes une a une du 

script l, verifie le cryptogramme MAC2 , et effectue de 
maniere atomique (c'est-a-dire en une fois et de 
maniere indivisible) action par action de la liste du 
script 1 et incremente le contenu CA du compteur apres 

25 chague action si celle-ci s'est bien deroulee. 

Lorsqu'une action s'est mal deroulee, le compteur 
d' action n'est pas incremente et les autres actions ne 
sont pas acceptees. 

- Af in de remonter au serveur la nouvelle valeur 
3 0 CA 7 du compteur d ' actions CA de la carte, plusieurs 

schemas sont possibles : 

- remontee lors d'un message d ' acquittement de la 
transaction en cours c'est-a-dire en temps reel, 
(correspond au message 3 de la transaction en cours) ; 
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- remontee de la valeur du CA' durant la 
prochaine transaction, (correspond au message 4 se 
produisant a 1' instant dtj); 

- a n'importe quel moment c'est a dire lorsque la 
5 carte envoie des informations au serveur. 

- Dans le cas de 1' exemple deer it, la carte renvoie 
un acquittement securise au serveur incluant le contenu 
CA' en temps reel. Celui-ci peut alors comparer ^ la 
valeur retournee par 1 ' acquittement avec la valeur 
10 stockee dans sa base. 

Si la valeur CA' = CA+n, n etant le nombres 
d' actions du script 1, ceci prouve que le script 1 
s'est deroule correctement dans la carte. Le serveur 
peut alors ef facer ce script dans la base de donnees. 

15 

On va maintenant decrire en relation avec la 
figure 2, en reprenant le meme exemple, ce qui se passe 
lorsque se produit une coupure ou une perte du message 
de demande d' actions (message 2). 
20 Dans ce cas de figure, la commande script 1 n'est 

pas arrivee dans la carte. Le serveur va devoir se 
resynchroniser . Le serveur est informe de cette 
situation car selon cet exemple il n'a pas regu 
d ' acquittement . 

25 Dans les cas ou le serveur n' attend pas 

d' acquittement , il est informe lorsqu'il recpoit la 
derniere valeur du compteur d' action de la carte e'est 
a dire par exemple lors de la prochaine transaction. 

En effet, durant 1 ' autrientif ication de la carte par 

30 le serveur (verification MAC1) le serveur identifie 
que cette carte n'a pas re<?u le script 1 (ou que le 
script 1 n'a pas ete effectue correctement dans la 
carte) grace a la valeur CA' du compteur d' actions qui 
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.est remontee au serveur et comparee a la valeur CA 
stockee dans le serveur. 

Si CA' est inferieur a CA et non egal, cela veut 
dire que la derniere ou les dernieres actions n'ont pas 
5 ete effectuees correctement . 

Dans ce cas le serveur remet a jour sa base de 
'donnees DB, en effkcant la valeur CA \ pour mettre la 
; valeur CA' . Le serveur est a nouveau* synchronise et 
peut relancer la ou les dernieres actions non executees 
10 par la carte. 

On va maintenant decrire . en relation avec la 
figure 3, en reprenant tou jours le meme exemple, ce qui 
se passe lorsque se produit une coupure lors du message 
d' acquittement. 

15 Ce cas ne peut etre envisage que dans le cas ou un 

message d ' acquittement est prevu par 1 'application. 
Mais le meme probleme peut se produire lorsque la 
remontee du compteur d' actions est effectuee au moment 
d'une demande d'une nouvelle transaction, ou de 1' envoi 

2 0 d'un message d 'information . 

Dans ce cas de figure, lors de la nouvelle demande 
de transaction, la valeur courante du compteur 
d' actions de la carte CA' = CA+n est remontee. 

Le serveur compare cette valeur CA' a sa derniere 

25 valeur stockee, c'est-a-dire CA. Comme CA' = CA+n, le 
serveur sait que les n dernieres actions ont bien ete 
menees, il stocke la nouvelle valeur du compteur 
d' actions, c'est-a-dire CA+n pour etre synchronise avec 
la carte. ' 
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RE VEND I CAT IONS 

1. Procede de controle de 1' execution d'une demande 
d' actions transmise par un serveur vers une carte via 
un terminal, ladite carte comportant un compteur 

) d' actions, caracterise en ce qu'il comporte les etapes 
5 } suivantes ; V ; 

a) a 1' emission par le serveur d'un message 
comportant une demande comprenant une ou plusieurs 
actions a mettre en oeuvre par la carte, le serveur 
stocke le nombre n d' action de la demande; 
10 b) a la reception du message, la carte execute 

successivement la ou les actions de la demande en 
incrementant son compteur d' actions entre chaque 
actions si 1' action s'est bien executee et en refusant 
cette action et les actions successives si 1' action ne 
15 s'est pas bien executee sans incremeriter son compteur. 

c) on compare la variation entre la valeur dans 

la carte et celle stockee dans le serveur et on 
determine que les x dernieres actions (commandes) ne 
sont pas executees si le resultat de la comparaison 

2 0 presente un ecart de x. 

2. Procede selon la revendication 1, caracterise en 
ce que pour comparer la variation entre la valeur dans 
la carte et celle stockee dans le serveur, la carte 

25 transmet au serveur la valeur courante de son compteur 
avant et apres execution de . la commande d'actions. 

3. Procede selon la revendication 1, caracterisee 
en ce que pour comparer la variation entre la valeur 

3 0 dans la carte et celle stockee dans le serveur, la 

carte calcule la valeur de la variation de son compteur 
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suite a 1' execution de la commande d' actions et la 
transmet au serveur . 

4. Precede selon l'une des revendications 2 ou 3 , 
caracterise en ce que la carte transmet ledites valeurs 
sous forme securisee. 

3 ) . ) 

5 . } Procede d'echange, de messages selon la 
revendication 1, caracterise en ce que la valeur du 
compteur d' actions de la carte est transmise en temps 
reel, e'est-a-dire pendant la transaction en cours . 

6. Procede d'echange de messages selon la 
revendication 5, caracterise en ce que la valeur du 
compteur d' actions de la carte est transmise au serveur 
au moyen du message d ' acquirement de la transaction en 
cours dans la carte. 

7. Procede d'echange de messages selon la 
revendication 1, caracterise en ce que la valeur du 
compteur d' actions de la carte est transmise en temps 
differe. 

8. Procede d'echange de messages selon la 
revendication 7, caracterise en ce que la valeur du 
compteur d' actions de la carte est transmise au serveur 
au moyen d'un message d'une nouvelle demande de 
transaction par la carte pour le serveur. 

'< , 

9. Procede d'echange de messages selon la 

revendication 7 , caracterise en ce que la valeur du 
compteur d' actions de la carte est transmise au moyen 
d'un message d ' information emis par la carte au 
serveur. 
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10, Carte pour mettre en oeuvre, le procede selon 
1'une des revendicat ions precedentes comportant un 
compteur et des moyens de gestion de ce compteur, 
5 caracterisee en ce que lesdits moyens de gestion sont 
aptes a incrementer ledit compteur ^d ' actions entre 
; chaque action si l'jaction s'est bien executees et a ne 
} pas 1 ' incrementer pour cette action ni ]pour les actions 
suivantes si cette action n'a pas ete executee. 



10 
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